This chapter describes the 2216 Web Server Cache feature. It contains the following:
Web Server Caching stores frequently requested Web pages for quick retrieval. Web Server Caching keeps frequently requested items closer to the clients; this frees up server resources currently being used for file serving and communication connections. The 2216 Web Server Cache provides high-speed access to Web pages while reducing host communications overhead. The 2216 Web Server Cache:
Note: | The Web Server Cache and the Host On-Demand Client Cache feature cannot co-exist in a configuration. |
All 2216 network interfaces that support TCP/IP connectivity, support connectivity between Web Server Cache, HTTP servers, and clients.
Figure 10 shows how Network Dispatcher works without Web Server Caching.
Figure 10. Network Dispatcher without Web Server Cache
Figure 11 shows how Network Dispatcher works with Web Server Caching and the requested page is not currently cached. Web Server Caching loads the response into the cache if the policies allow it.
See "Using the HTTP Proxy" for information about HTTP Proxy.
A partition is a division of the cache core memory. Each cache
partition is configured independently and allows the device to support
multiple sites.
Figure 11. Network Dispatcher with Web Server Cache and No Cache Hit
It is important that the administrator realize that the destination address for packets destined to the server is the server address and not the cluster address, as stated in step 6 above. The issue is important when a Web server is configured on a host: if the Web server is configured to listen on a specific IP address, that IP address must be the server interface IP address. More generally, the server interface will have a set of logical IP addresses assigned to it. When the Network Dispatcher cluster is configured to use a server logical IP address, the corresponding Web server must be configured to listen on that logical IP address. Hence, one host (server) may have several Web servers, each listening on a different logical IP address. Network Dispatcher can be configured with separate clusters for each Web server. In this way, one host can be used for a number of Web sites. Also a separate cache partition needs to be used for each Web Server. When the Web Servers are on replicated hosts, multiply the number of replicated hosts times the number of Web Servers to determine the number of server addresses used.
In addition, the number of cluster addresses should be aliased on each host's loopback address; then if a cache partition is disabled, the Web Server will continue to be reachable, as the Network Dispatcher falls back to simple port mode zero (no caching). The fallback operation is guaranteed only for direct attached servers; otherwise, routing might be unwieldy or impossible.
Figure 12 shows how Network Dispatcher works with Web Server Caching when the requested page is currently cached.
Figure 12. Network Dispatcher with Web Server Cache and Cache Hit
The 2216 Web Server Cache has:
The alternative to transparent (automatic) caching is manual caching. In this case, an external agent uses the cache manager to cache a Web page. For information about externally controlled Web caching see External Cache Control Manager Overview.
Stale cached objects are automatically deleted. The 2216 Web Server Cache supports both HTTP 1.0 and 1.1 servers and clients.
Flow chart for transparent caching policies:
Note: | The backup server cache comes up empty. You must repopulate the backup server cache by using either transparent caching (For example: requests for URLs) or by using the external cache control manager function to force pages into the cache. |
Each HTTP Proxy represents a cluster address/port that is doing caching. There can be multiple HTTP proxies that uses a cache partition.
The HTTP Proxy handles receiving requests from clients and tries to satisfy them from its cache partition. If the HTTP Proxy can satisfy the request, it responds back to the client. If the HTTP Proxy cannot satisfy the request, it opens a TCP connection with a server in an attempt to satisfy the request. When the server responds to the HTTP Proxy's request, the HTTP forwards the server's response to the client. The HTTP Proxy also sees if the response from the client should be cached. If the response should be cached, the HTTP Proxy passes it to the cache partition.
HTTP Proxy handles connections using the following guidelines.
Status codes:
Note: | The Web Server Cache is an extension to the server and therefore does not use the Cache-Control header like HTTP Proxy caches. |
Note: | If a partial GET request has more than ten ranges, the entire response will be returned. |
Note: | If a persistent connection comes in from an HTTP 1.0 level client and the response is returned from the cache it will append a Connection header based on the request. For example, if the client wants a long-lived connection, it will maintain a long-lived connection. |
Scalable High Availability Cache allows a group of connected Web Server Caches to function as one large cache. The maximum number of caches in a group is sixteen. A failure with one cache member reduces the total amount of memory available for caching, rather than end all cache functions. See Figure 17 for a configuration example.
The individual caches make up the total cache space. If a cache becomes nonfunctional, incoming pages will continue to be cached by the remaining working caches.
Incoming Web pages are stored in the group's caches. They are distributed evenly among the available caches. Each cache in the group maintains a table that tracks the number of reachable caches in the group and their IP addresses. The tables are identical for all caches in a group. The tables are used along with a Cache Array Routine Protocol (CARP) algorithm to determine which cache owns a particular URL. The information for the table comes from the Network Dispatcher device and indirectly from the caches that are using the HTTP advisor to keep track of the status of the Web Server Caches in the group. The following figures demonstrate the conditions for locating a URL using SHAC.
Figure 13 shows the request from Network Dispatcher found in the first cache that received the request.
Figure 13. Cache Request Found
Figure 14 shows a request not found in the first cache that received the request from Network Dispatcher and the CARP algorithm indicates that another cache owns the URL.
Figure 14. Request Forwarded to the Responsible Cache
Figure 15 shows a request not found in the cache that received the request from Network Dispatcher, but the CARP algorithm indicates that the cache is responsible for the URL.
Figure 15. Request Forwarded to Backend Server
Figure 16 shows a request that is not found in any cache in the cache group.
Figure 16. Request Forwarded to the Responsible Cache and Not Found
Note: | In Figure 15 and Figure 16, it is to be understood that all caches in the group are to be connected to all backend servers in the pool to achieve maximum reliability. |
Figure 17 shows a tested example of SHAC with detailed configuration parameters used in conjunction with "Using Network Dispatcher with Scalable High Availability Cache (SHAC)", "Configuring and Monitoring the Network Dispatcher Feature" and "Configuring and Monitoring Web Server Cache". The interface addresses, internal addresses, cluster addresses, and the server IP address are shown along with the subnet masks. Also shown are routing commands needed for the caches and the backend server that is connected to the 113 Ring.
Figure 17. Two caches with Network Dispatcher, client and backend server
The External Cache Control Manager allows Web servers the ability to control the Web Server Cache and the Host On-Demand Client Cache. This control is by way of a user-defined port for the External Cache Control Manager (ECCM). The ECCM accepts connections and processes commands targeted for a partition over this port. The commands use the External Cache Control Protocol (ECCP). The ECCP uses vector/subvector formats to send request commands and response commands.
One command vector can request multiple functions by having multiple subvectors. Each subvector represents a new function. The command vector indicates to which cache partition the commands are applied by specifying the cluster address and the port of a proxy defined on that partition.
The following functions are supported by ECCP:
The External Cache Control Manager allows you to create a dependency table for each cache partition. This table is particularly useful when dealing with dynamic objects in the cache.
Note: | Caching dynamic objects requires that the objects be updated when the information from which these objects were created changes. |
The information to build the dependency table must be passed to the cache
partition using the External Cache Control Manager interface.
The dependency table gives you the ability to assign a dependency string to
a set of URL object s(cached Web pages). These dependencies are stored
in dependency tables in the Web Server Cache by using the External Cache
Control Manager interface. The dependency table is used to invalidate
objects in the cache partition that have this dependency when the source for
the object changes. Without a dependency table, you would have to send
a separate delete command for each object to be deleted.
Example: The following three databases contain various objects.
database1 database2 database3 --------- --------- --------- object_a object_a object_b object_b object_c object_e object_c object_d
Assume that all the pages object_a through object_e are in the cache. If database2 changes, you can send (via Cache Control Manager interface) an invalid dependency database2 command. The Web Server Cache will then delete object_a, object_c, and object_d from the cache partition.
Note: | An object does not need to be in the cache partition to be in the dependency table. |
The External Cache Control Manager allows you to control user access. This is accomplished by requiring incoming connections to have a userid and password. The userid and password are tied to the logon userid and password. If the device is password protected and the incoming connection does not have a userid and password or the userid and password are not valid, an authentication error response is returned and the connection is closed. If the userid and password are valid, the user may send commands over that interface.
Security provides a way to authenticate the ECCP user. Four types of authentication can be configured (RADIUS, TACACS, local, or none). Data encryption is not provided. Each authentication mechanism (except for none) requires both a user ID and associated password. This information is passed to the 2216 using the authentication vectors. The user ID can range from 1-8 bytes, while the password can range from 1-8 bytes. The password passed on the External Cache Control connection must be encrypted using DES encryption. The random 8 byte seed used for the encryption is also passed. The key for the encryption will not be passed over the connection. See "Modify" for information about setting the port and TCP values.
Note: | The Authentication vector will be ignored if the router is not password protected. |
The External Cache Control Protocol (ECCP) gives the back-end servers the ability to control the router cache. This control maximizes cache performance.
The ECCP is an architected protocol interface that allows the servers to add and delete objects as well as modify the cache policies.
The external cache control manager is defined in the router (Web Server Cache or Host On-Demand Client Cache) to accept connections and process commands targeted for a cache partition.
The external cache control manager is configured with the following parameters:
Valid Values: 0 to 65535
Default Value: 0
Valid Values: 5 to 240 seconds
Default Value: 120
This section describes the functions of the External Cache Control Manager.
An HTTP response object can be added to the cache partition. The format of the object data must be the same as an HTTP response. The External Cache Control Manager will parse the headers of the response and pull out the information that is needed. Then the object is added to the cache.
The difference between the Add Object and the Add (Force) Object is that the Add (Force) Object will ignore any Cache_Control headers specifying DO or DONT. All other headers that the HTTP Proxy use to determine whether to cache an object are still used. For both Add Object and Add (Force) Object the object will be replaced in the cache partition regardless of the date.
An HTTP object can be deleted from the cache. The URL for the object is given.
The dependency table for a cache partition can be modified, listed, and used to invalidate objects.
When modifying the dependency table (adding or removing dependencies), both the dependency and the dependency URL must be given. In addition, there are two other ways to modify the dependency table. One is to reset the entire table, an entire dependency (i.e. remove the dependency completely), or a URL dependency (i.e. remove the URL dependency from all dependencies). The other is to do a garbage collect on the dependency table. The garbage collect cleans up all the dependency URLs from the dependency table that do not have an object with that URL in the cache.
There are multiple ways of listing the information in the dependency table. The entire table can be retrieved, all the dependency URLs for a given dependency can be retrieved, or all the dependencies that have a give dependency URL can be retrieved.
Objects can be removed (invalidated) from the cache using the Dependency Table. Using the dependency, the Dependency Table is checked. Any dependency URL for that dependency will be removed from the cache partition.
This function allows the cache partition state to be changed. In order to use the External Cache Control Manager the cache partition must be in the correct state. The cache partition must be disabled in order to purge all the objects from it.
The policies for a partition can be listed or modified. Each policy can be done separately or as a group. When modifying a policy, the correct type of data must be passed for that policy. See External Cache Control Protocol (ECCP) Vector Formats (Policy Command Subvector and Policy Response Subvector) for the format of the data based on the policy.
This function allows all the objects in the cache partition to be removed. The cache partition must be in the disabled state in order to purge it.
This function gives the ability to see if an object is in the cache partition. In addition, if the object is in the cache partition and has a last modified date, that date is returned. See "External Cache Control Protocol (ECCP) Vector Formats" (Query Response Subvector) for the format of the date returned.
This function gives the ability to list and reset (clear) the cache partition statistics. See "External Cache Control Protocol (ECCP) Vector Formats" (Statistics Response Subvector) for the format of the statistics.
This function gives the ability to list and modify the URL masks for a cache partition. The URL type include, exclude, dynamic, or Host On-Demand Client Cache applet must be given when using this function. You must list one URL type. This function does not work with multiple URL types.
You have the ability to add a URL mask. If the URL mask is an include, dynamic, or Host On-Demand Client Cache applet mask the lifetime needs to be given. Adding a dynamic mask will modify the current dynamic URL mask and adding a Host On-Demand Client Cache applet mask will modify the current Host On-Demand Client Cache applet mask. You have the ability to delete a URL mask. This function is not valid for the dynamic URL mask or the Host On-Demand Client Cache applet mask. You have the ability to reset all the URL masks of a peculiar type. Resetting the dynamic URL mask resets to the default dynamic URL mask and resetting the Host On-Demand Client Cache applet mask resets to the default Host On-Demand Client Cache applet mask.
Note: | The dynamic mask is used with Web Server Cache images and the Host On-Demand Client Cache applet mask is used with images that have the Host On-Demand Client Cache feature. |
The ECCP clients sends commands and receives responses using a vector format. The authentication vector is required if the box is password protected. If the box is not password protected the authentication vector is ignored when received.
This section describes the field descriptions for the Vectors.
Figure 18. Command Response Vector
Length: The unsigned 32-bit value representing the length
(in bytes) of the entire vector, including the length and key fields, as well
as any subvectors and subfields. The acceptable range is:
Key: The unsigned 16-bit value representing the major vector key. The major vector keys are:
Cluster IP: The 32 bit IP address of the cache cluster associated with the target cache partition.
Port: The 16 bit Port number of the cache cluster associated with the cache partition.
Correlator: The unsigned 32-bit value used by ECCP client to associate the command response to the command request.
Retcode: The unsigned 32-bit value representing the return code. This is only present in the response vectors.
Vectors contain one or more subvectors. The authentication request vector requires both the name and the password subfields. The command request vector contains one or more command subvectors. If multiple subvectors are present in the command request vector, then multiple subvectors will be present in the command response vector. If a severe error occurs, it is reflected in the Retcode field of the command response vector.
The Authentication Request Vector must be the first vector on the External Cache Control Connection if the box is password protected. If the box is not password protected this vector will be ignored.
The length (in bytes) of the vector, including the length and key fields, as well as any subvectors.
0x4A00
Reserved for future use.
The Command Request Vector sends commands to the External Cache Control Manager. If the box is password protected a valid Authentication Request Vector must first be received by the External Cache Control Manager before the commands are accepted.
The length (in bytes) of the vector, including the length and key fields, as well as any subvectors.
0x4B00
The port number of the cache cluster (HTTP Proxy) associated with the
target cache partition. The IP address of a cache cluster (HTTP Proxy) associated with the target
cache partition.
The correlator is used to associate the command responses to its matching
command request.
One or more of the following subvectors may be appended.
The Authentication Response Vector is returned in response to an Authentication Request Vector.
The length (in bytes) of the vector, including the length and key fields, as well as any subvectors.
0x4A01
Reserved for future use.
This is the return code for the vector. See "Return Codes".
There are currently no vectors on the Authentication Response
Vector.
The Command Response Vector is returned in response to a Command Request Vector.
The length (in bytes) of the vector, including the length and key fields, as well as any subvectors.
0x4B01
The port number of the cache cluster (HTTP Proxy) associated with the
target cache partition. The Cluster IP Address of a cache cluster (HTTP Proxy) associated with the
target cache partition.
The correlator is used to associate the command responses to its matching command request.
This is the return code for the vector. See "Return Codes".
Zero or more of the following subvectors may be appended.
This section describes the subvector formats. Subvectors follow the same basic format as the major vector:
Length: The unsigned 32-bit value representing the length (in bytes) of the entire subvector, including the length and key fields as well as any subfields. The acceptable range is 6-4 GB (we are not checking the upper bound)
Key: The unsigned 16-bit value representing the subvector key. The request subvector keys include:
The response subvector keys returned are:
Reserved: A 16 bit field not currently used.
Retcode: The unsigned 32-bit value representing the return code for the request subvector. This is only present in the response subvector.
The Add Object Command Subvector is used to add a Web Object to the cache partition.
The length (in bytes) of the vector, including the length and key fields,
as well as any subvectors.
0x0100
The Add (force) Object Command Subvector is used to add a Web object to the cache partition. It differs from the Add Object Command Subvector in that any Cache Control headers of the object are ignored.
The length (in bytes) of the vector, including the length and key fields,
as well as any subvectors.
0x0110
The Delete Object Command Subvector is used to remove a Web object from the cache partition.
The length (in bytes) of the vector, including the length and key fields, as well as any subvectors.
0x0400
The Dependency Command Subvector is used to modify/list the Dependency Table or invalidate objects using the Dependency Table.
The length (in bytes) of the vector, including the length and key fields, as well as any subvectors.
0x0A00
The dependency Command to be performed.
The dependency type field is used to identify data to be changed.
This data is then changed using the Dependency Command.
Dependency Subfield
Note: This subfield must be first when both subfields are required.
Required when have these Command-Dependency Type.
Command Dependency Type
0x0001 0x0002
0x0002 0x0000
0x0003 0x0000
0x0004 0x0002
0x0005 0x0000
URL Subfield
Note: This subfield must be second when both subfields are required.
Required when have these Command-Dependency Type.
Command Dependency Type
0x0001 0x0003
0x0002 0x0000
0x0003 0x0000
0x0004 0x0003
The Disable Command Subvector is used to disable a Cache Partition.
The length (in bytes) of the vector, including the length and key fields, as well as any subvectors.
0x0300
The Enable Command Subvector is used to enable a Cache Partition.
The length (in bytes) of the vector, including the length and key fields, as well as any subvectors.
0x0200
The Policy Command Subvector allows you to modify a cache partition or list the information in a cache partition.
The length (in bytes) of the vector, including the length and key fields, as well as any subvectors.
0x0500
The command to be performed.
The Policy Type is used to identify data to be changed. This data is
then changed using the Policy Command.
If the policy Type = 0x0001, 0x0002, 0x0003, 0x0004, or 0x0005:
If the Policy Type = 0x0006, 0x0007, or 0x0008
The range is 0 to 10080, with 0 representing an object with no expiration.
If the Policy Type = 0x0009
The range is 0 to 720, with 0 indicating that garbage collection should be disabled.
If the Policy Type =0x000A
Note: | The value is not verified. |
If the Policy = 0x000B
The range is 0-100000, with 0 indicating no limit.
Note: | The value is not verified. |
If the Policy = 0x000C
The range is 512 to 300000, entering a 0 indicates no limit.
Note: | The value is not verified. |
If the Policy = 0xFFFF
The range is 0 to 4095, with 0 indicating no limit.
Note: | The value is not verified. |
The range is 0 to 1000000, with 0 indicating no limit.
Note: | The value is not verified. |
The range is 512-3000000, specifying 0 indicates no limit.
Note: | The value is not verified. |
The range is 0 to 10080, with 0 representing an object with no expiration.
Note: | The value is not verified. |
The range is 0 to 10080, specifying 0 indicates no limit.
Note: | The value is not verified. |
The range is 0 to 10080, with 0 representing no limit.
Note: | The value is not verified. |
The range is 0 to 720, with 0 indicating that garbage collection must be enabled.
The Purge Command Subvector is used to clear all the objects from a cache partition.
The length (in bytes) of the vector, including the length and key fields, as well as any subvectors.
0x0600
The Query Command Subvector is used to check if a given URL is in the cache partition.
The length (in bytes) of the vector, including the length and key fields, as well as any subvectors.
0x0700
The Statics Command Subvector is used to get/reset the statistics for a cache partition.
The length (in bytes) of the vector, including the length and key fields, as well as any subvectors.
0x0800
The URL Mask Command Subvector is used to list/modify the URL masks associated with a cache partition.
The length (in bytes) of the vector, including the length and key fields, as well as any subvectors.
0x0900
The range is 0-10080, with 0 representing an object with no
expiration. Used only for Add (0x0002) command when URL type is Include
(0x0001), Dynamic (0x0003), or Host On-Demand Client Cache applet
(0x0004).
Note: Deleting the dynamic URL mask or the Host-On-Demand Client Cache applet mask
is an invalid function.
The Add Object Response Subvector is used to respond to an Add (force) Object Command Subvector.
The length (in bytes) of the vector, including the length and key fields, as well as any subvectors.
0x0101
See "Return Codes".
The Add (force) Response Subvector is used to respond to an Add (force) Object Command Subvector.
The length (in bytes) of the vector, including the length and key fields, as well as any subvectors.
0x0111
See "Return Codes".
The Delete Object Response Subvector is used to respond to an Add (force) Object Command Subvector.
The length (in bytes) of the vector, including the length and key fields, as well as any subvectors.
0x0401
See "Return Codes".
The Dependency Response Subvector is used to respond to a Dependency Command Subvector.
The length (in bytes) of the vector, including the length and key fields, as well as any subvectors.
0x0A01
See "Return Codes".Dependency Subfield
Note: This subfield must be before the URL Command Subfields that are for
the dependency. Required when have these Command-Dependency Type. For
more information see Dependency Command Subvector.
Command Dependency Type
0x0001 0x0001 Note: Any URL Subfields following
the Dependency Subfield are
dependency URLs on that
dependency.
0x0001 0x0003
URL Subfield
Note: This subfield must be second when both subfields are required.
Required when have these Command-Dependency Type.
Command Dependency Type
0x0001 0x0001 Note: The Dependency Subfield prior
to the URL Subfield indicates
the URL for the dependency.
0x0001 0x0002
The Disable Response Subvector is used to respond to the Disable Command Subvector.
The length (in bytes) of the vector, including the length and key fields, as well as any subvectors.
0x0301
See "Return Codes".
The Enable Response Subvector is used to respond to the enable Command Subvector.
The length (in bytes) of the vector, including the length and key fields, as well as any subvectors.
0x0201
See "Return Codes".
The Policy Response Subvector is used to respond to the Policy Command Subvector.
The length (in bytes) of the vector, including the length and key fields, as well as any subvectors.
0x0501
See "Return Codes".
If the policy Type = 0x0001, 0x0002, 0x0003, 0x0004, or 0x0005:
If the Policy Type = 0x0006, 0x0007, or 0x0008
The range is 0 to 10080, with 0 representing an object with no expiration.
If the Policy Type = 0x0009
The range is 0 to 720, with 0 indicating that garbage collection should be disabled.
If the Policy Type =0x000A
Note: | The value is not verified. |
If the Policy = 0x000B
The range is 0-100000, with 0 indicating no limit.
Note: | The value is not verified. |
If the Policy = 0x000C
The range is 512 to 300000, entering a 0 indicates no limit.
Note: | The value is not verified. |
If the Policy = 0xFFFF
The range is 0 to 4095, with 0 indicating no limit.
Note: | The value is not verified. |
The range is 0 to 1000000, with 0 indicating no limit.
Note: | The value is not verified. |
The range is 512-3000000, specifying 0 indicates no limit.
Note: | The value is not verified. |
The range is 0 to 10080, with 0 representing an object with no expiration.
Note: | The value is not verified. |
The range is 0 to 10080, specifying 0 indicates no limit.
Note: | The value is not verified. |
The range is 0 to 10080, with 0 representing no limit.
Note: | The value is not verified. |
The range is 0 to 720, with 0 indicating that garbage collection must be disabled.
The Purge Response Subvector is used to respond to a Purge Command Subvector.
The length (in bytes) of the vector, including the length and key fields, as well as any subvectors.
0x0601
The Query Response Subvector is used to check if a given URL is in the cache partition.
The length (in bytes) of the vector, including the length and key fields, as well as any subvectors.
0x0701
See "Return Codes".
Note: | This field will not exist if the return code was not 0x00000000 or if it is not known by the Cache Partition. |
The Statistics Response Subvector responds to the Statistics Command Subvector.
The entire length (in bytes) of the vector, including the length and key fields, as well as any subvectors.
0x0801
This is the return code for the subvector.
The URL Mask Response Subvector is used to respond to a URL Mask Command Subvector.
The length (in bytes) of the vector, including the length and key fields, as well as any subvectors.
0x0901
This is the return code for the subvector. See "Return Codes".
This section describes the field descriptions for the subfields.
Figure 20. Subfield Format Partial Length: The unsigned 32-bit value representing the
length (in bytes) of the entire subfield, including the length and key fields,
but excluding the padding bytes. The subfields are padded so that they
will be aligned with the 4-byte (word) boundaries. The acceptable range
is 6 to 4GB.
Key: The unsigned 16-bit value representing the subfield key. The command subfield keys include:
The response subfield keys are:
Reserved: A 16 bit field currently not used.
The Dependency Subfield for the URL Mask Response Subvector.
The length (in bytes) of the subfield as in Figure 20.
0x0050 - request
0x0051 - response
The dependency must be 1 to 50 in length.
The Name Subfield for the URL Mask Response Subvector.
The length (in bytes) of the subfield as in Figure 20.
0x0030 - request
The name Must be 1 to 8 in length.
The Object Subfield for the URL Mask Response Subvector.
The length (in bytes) of the subfield as in Figure 20.
0x0020 - request
The object must be formatted like a HTTP Response. It is an array of characters.
The Password Request Subfield for the URL Mask Response Subvector.
The length (in bytes) of the subfield as in Figure 20.
0x0040
The password must be 1 to 8 bytes in length and be encrypted.
The URL Request Subfield for the URL Mask Response.
The length (in bytes) of the subfield as in Figure 20.
0x0010 - request
0x0011 - response
This URL or URL Mask is an array of characters, the array must be 1 to 255
in length.
It is important to check the return codes for each response subvector in addition to the return code in the response vector. The return code for the response vector will be set to a non-zero value if a severe error was detected, in which case all the command subvectors from the command vector might or might not have a corresponding response subvector.